Version 0 and 1 can have some content after SliceContent #112
+9
−0
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
From the debate in #110, I propose a different method for avoiding to have streams created by
"ffmpeg -c ffv1 -level 1 -slicecrc 1
considered as non conforming to specification.This patch synchronizes specification with behavior of the decoder (which ignores the extra bits) by permitting the extra bits. It also add a note for people who would revise the specification about the risk of using 40 bits of the reserved part.
This patch does not prevent us to change our mind about #110 in the future.
Additional note: the extra bits are authorized only for versions 0 and 1 due to the existence of such bistream (not expected, but they are there) in the wild. "feature" of not having extra bits in version 3 is used by some decoders for being able to decode first slices (when latest bytes of a frame are missing, FFmpeg decoder decodes only the first slice, my own decoder uses the lack of reserved bits in the bitstream for parsing all slices up to the missing bytes by starting from the beginning and parsing all slices sequentially).